Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NEW : Billing Term field database #32129

Open
wants to merge 14 commits into
base: develop
Choose a base branch
from

Conversation

atm-irvine
Copy link
Contributor

NEW|New Billing term field for model invoice

First PR for new field billing term in database : this field will allow to choice prepaid or postpaid for model invoice.

@@ -68,6 +68,7 @@ create table llx_facture_rec
usenewprice integer DEFAULT 0, -- update invoice with current price of product instead of recorded price
frequency integer, -- frequency (for example: 3 for every 3 month)
unit_frequency varchar(2) DEFAULT 'm', -- 'm' for month (date_when must be a day <= 28), 'y' for year, ...
billing_term integer DEFAULT 0,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you provide more information on the differznce between this field and the existing one fk_cond_reglement ?
May be provide 2 use case for each value ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have introduced a new field called billing_term to the model, with two possible values: postpaid or prepaid. By default, models are set to prepaid, meaning that invoice lines will reflect the dates of the current billing period when the invoice is generated. If the billing_term is set to postpaid, the invoice lines will instead correspond to the previous billing period. For instance, in a monthly billing cycle, a prepaid invoice for January would reflect January's dates, while a postpaid invoice generated in January would reflect December's dates. Similarly, for a quarterly cycle, a postpaid invoice generated for Q2 would cover the dates for Q1.

This differs from the fk_cond_reglement field, which governs the payment terms, such as whether payment is due upon receipt, within 30 days end-of-month, or within 10 days. While billing_term determines the period referenced in the invoice lines (current or prior), fk_cond_reglement defines when payment is expected, addressing distinct parts of the invoicing process.

Use Case Example: Consider a subscription service. For a prepaid model, the customer is billed at the start of January for services to be delivered in January. In contrast, for a postpaid model, the customer is billed at the start of January for services delivered in December. This allows flexibility in how the company aligns its invoicing practices with its operational or contractual obligations.

Copy link
Member

@eldy eldy Nov 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see.
So the new field is not related to how the payment term will be filled but to how the field start/end on lines will be filled. You suggest 2 different rules but ibthink in a future we may have more.
So i suggest to rename the field into another name like
rule_for_lines_dates
Value can be 'prepaid or 'postpaid', so i suggest to use a varchar to store the rule. In a future, we may have complex rule, like prepaid:+3:-1 to have start date 3 days after and end date 1 day before for exemple.

@eldy eldy added the Discussion Some questions or discussions are opened and wait answers of author or other people to be processed label Nov 28, 2024
@atm-maxime
Copy link
Member

@eldy is the explanation ok for you ?

@eldy eldy added PR to fix - OK to merge if suggested fix are done PR was analyzed by PR merger and seems ok to be merged as soon as a fix has been published and removed Discussion Some questions or discussions are opened and wait answers of author or other people to be processed labels Nov 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR to fix - OK to merge if suggested fix are done PR was analyzed by PR merger and seems ok to be merged as soon as a fix has been published
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants